Originally by: Bartholomeus Crane

---

Edited by: Bartholomeus Crane on 18/09/2008 18:16:30
This is an interesting insight into how EVE uses optimistic predicting concurrency to reduce bandwidth and computing power problems, but it also shows its inherent problem. The use of causality envelopes is fine as long as they partition the possible statespace without too many intersections. When they don't, for example when all causality envelopes intersect, the problem becomes as intractable and indivisible as before. As such, I believe, it solves the problem in the general case, but offers worst-case performance when it doesn't. Only that in EVE the non-general case, i.e., large fleet battles, has become common.

I wonder if CCP has considered taking this approach one step further and introduce optimistic prediction in the non-general case as well, i.e., loosening causality when several causality envelopes intersect, perhaps even doing so recursively over different layers. This assumes that individual behaviour in the non-general case is predictable, which doesn't necessarily have to be so (although, to a large extend, I suspect it is).

It also comes with a drawback, because the expected incident rate of sending a negative delta correction will increase with more erratic behaviour, and it assumes that the computing power is available to catch up in time (eventually). Also, it means the client will duplicate some functionality so that it can handle things concurrently, irrespective of responses from the server, thus losing it's 'dumb client' status (which I now wonder it actually has).

Moreover, in the non-general case, some causality between the players actions and the servers reactions will be lost. It should however, I would argue, provide a certain buffer for lag in the non-general case, even if limited in the temporal sense (temporal in the predictable behavioural sense I mean, i.e., for as long as the behaviour is erratic or unpredictable). Still, the question remains if there is enough stretch in bandwidth to make this feasible, which is a question I can't answer without further data (if EVE is still supposed to be played on a dail-up modem, I doubt there is).

OK, lots of assumptions from my part, and maybe I misunderstood what was being quoted (it's not very rigorous, nor am I, I admit), but it appears to me that the implementation should work fine in general, but falls down in crowded situations, and this should, really, have been apparent from the beginning (and is actually the behaviour we see). Perhaps the above can be of some use in resolving this issue.

---